This invention relates to operating system software, and more particularly, to a method and apparatus for decreasing an execution time of system calls in a data processing system.
Data processing systems commonly are controlled by a software program called an "operating system" (OS). The operating system acts as the "brains" of the data processing system and controls the scheduling and execution of other software programs being executed by the data processing system. These other software programs are called "application programs" or "processes". The UNIX operating system is an example of a commonly used operating system. UNIX is a registered trademark in the United States and other countries exclusively licensed through X/OPEN, Ltd. Sun Microsystems, Inc. manufactures a version of UNIX called Solaris, which is a registered trademark of Sun Microsystems, Inc.
An operating system controls the performance of many common system operations, such as printing data to a printer or reading data from a document scanner. Thus, if an needs to read or write data, it does so by "calling" the operating system and requesting that the operating system perform a "system call function." The operating system performs the system call function, such as reading or writing, and returns a result to the application program.
The UNIX operating system is formed of two separable parts: the kernel and the systems programs. Systems programs include system libraries, compilers, interpreters, shells, and other such programs that provide useful functions to application programs user. The kernel provides the file system, CPU scheduling, memory management, and other operating-system functions by responding to system calls from application programs. Conceptually, the kernel sits between the hardware and the application programs. System calls are made by a "trap" to a specific location in the computer hardware. Specific parameters are passed to the kernel on the stack and/or in registers and the kernel returns with a code in specific registers or memory locations indicating whether the action required by the system call was completed successfully. For more detailed information on the UNIX operating system see "The Design of the UNIX Operating System" by Maurice J. Bach, Prentice-Hall, 1986, which is herein incorporated by reference.
Some data processing systems execute application programs that consist of multiple processes. Other data processing systems allow each process to contain multiple "threads." Still other data processing systems allow programs to be re-structured to make use of more than one hardware processor (CPU) at a time. Such programming capabilities are generally embodied in a programming paradigm called "multi-threading." A "thread of control" or more simply, a "thread" is a sequence of instructions being executed in a program. Each thread has a program counter and a stack to keep track of local variables and return addresses. Threads execute independently of other threads. A thread shares the instructions of its process, and most of the data of the process, as well as sharing the operating system state of its process. Each thread may make arbitrary system calls. Threads and the associated controls and services of a multi-threaded system may be implemented as objects.
Multi-threaded systems are described, for example, in "SunOS Multi-thread Architecture" by M. L Powell, S. R. Kleiman, S. Barton, D. Shah, D. Stein, M. Weeks, Proceedings of the USENIX Conference--Winter '91--Dallas, Texas, pages 65-79, which is herein incorporated by reference. Additional information concerning the implementation of the SunOS 5.0 may be found in the following articles; each of which is herein incorporated by reference. S. Kleiman, J. Voll, J. Eykholt, A. Shivalingiah, D. Williams, M. Smith, S. Barton, and G. Skinner, "Symmetric Multiprocessing in Solaris 2.0," COMPCON Spring 1992, p. 181, San Francisco, Calif.; Sandeep Khanna, Michael Sebree, John Zolnowsky, "Realtime Scheduling in SunOS 5.0," USENIX, Winter 1992, San Francisco, Calif.
The software of an operating system typically contains special programs (or "handlers") that execute systems calls from threads. The operating system typically performs certain tests before performing the function requested by the system call. Tests performed by the operating system before the requested system call function is executed by the kernel are called "pre-tests." For example, the operating system may test to determine whether the system is operating in "debug" or "TRACE" mode before executing a system call function. Some pretests have actions associated therewith that are performed when a condition in the pre-test is true. The operating system also typically performs certain tests after performing the function requested by the system call. Tests performed after the requested system call function is executed are called "post-tests." For example, the operating system may test for the existence of non-standard error codes after executing a system call function. Some post-tests have actions associated therewith that are performed when a condition in the post-test is true.
As operating systems have become larger and more complicated, the number of pre-tests and post-tests that the operating system performs in connection with each system call has increased. Because the tests are performed for each system call, even relatively simple system calls that would otherwise execute in a short period of time have begun to take relatively long periods of time to execute. What is needed is a way to avoid execution of multiple pre-tests and pre-tests or post-tests are known to be inapplicable.
Accordingly, there is a need for a way to decrease system call execution times.